過了 Research 和 Serving 環節,接著進入 Monitoring 環節,我認為如果一個資料科學團隊要開始搭建 MLOPs 系統,最先要開始的絕對是 Monitoring,而這裡的 Monitoring 定義為: 主動發現錯誤,並通知相關人員進行修復,通知的部分不會是我們著墨的地方,可以透過公司內部的通訊軟體洛是 PagerDuty 這類的服務來做到,而在這篇開始我們先來探討錯誤的類別
從粗暴到抽象,或說從容易發現到不容易發現我們可以歸類為以下幾層的錯誤類別
整個 Monitoring 可以簡單分成三款
這裡的 Data Collector Based 是指將 Inference Endpoint 收到的 Request 以及傳出去的 Response 收集到一個可觀察的日誌,常見的做法是蒐集 Elastic Search 並透過一些 Query, Kibana Dashbaord Metrics 來監控異常。這裡主要要做到的是搭建一套以 Endpoint 本身為對象的 observability stack, Prometheus Grafana
當有了基本的 Observability,就可以進一步得針對異常做 Alarm 系統,把 Endpoint 側錄下的 Request 和 Response 資訊透過 Message Queue 傳給用於分析的 Pipeline 來觀測是否有異常值,我會歸類這一類的目的是從 Event Sequence 上去實作 Anomaly Detection , Anomaly Detection 我認為是一個很大的題目,但我們可以從
總結來說,Data Collector Based Monitoring 有幾個特點
在經驗上來說,如果要實踐這樣的觀測,MLOPs 在設計時就必須考慮模型的 Request 和 Response 怎麼去做封裝,舉個例子,如果用戶輸入的特徵是一個數值,通常你可以直接用如標準差這樣的統計方法來偵測異常,但如果用戶輸入的是一串字串,那他是表達一種 Category 還是一個日期就會有很不一樣的處理方式,如果都當字串處理,就很難去做一個可以 Generalize 的 Data Collector Based Monitoring